Jak rozdelit aplikaci?

Otázka od: CERMAK

23. 10. 2002 12:24

Ahoj vsichni

Mam velkou databazovou aplikaci. Nevite, jak ji vhodne rozdelit, aby bylo
mensi Exe. Balicky, COM, .... Jake mate zkusenosti. Co bude nejjednodussi a
nejefektivnejsi na rychlost natahovani casti a na spotrebu pameti.

 
                     Jaromir Cermak

Odpovedá: Petr Vones

23. 10. 2002 13:52

From: "CERMAK" <CERMAK@procom.cz>
> Mam velkou databazovou aplikaci. Nevite, jak ji vhodne rozdelit, aby bylo
> mensi Exe. Balicky, COM, .... Jake mate zkusenosti. Co bude nejjednodussi a
> nejefektivnejsi na rychlost natahovani casti a na spotrebu pameti.

EXE se do zadne 'pameti' nenatahuje, protoze ve Windows zadna 'pamet' neni.
Velikost EXE souboru nema mnoho spolecneho s tim, jak rychla aplikace je nebo
jak rychle se spusti. V beznem procesu je totiz stejne namapovano nekolik MB
systemovych knihoven, takze tvoje aplikace je jen malou casti. Pokud aplikaci
slozis z ruznych DLL a COMu tak to bude spise pomalejsi, komplikovanejsi a
zabirajici vice prostredku.

Nez sledovat fyzickou velikost EXE souboru (ktera muze byt treba klidne 50M
obsahujici napriklad velke resource, ale spusti se temer ihned, protoze se ty
resource vubec nikdy neprectou) je mozna lepsi programovat efektivne. Tedy
nevytvaret vsechny formulare pri startu aplikace, ale teprve tehdy az jsou
potreba a pak je zase uvolnit, vyvarovat se neefektivnich algoritmu, obcas se
podivat jak se nektery kod v Object Pascalu prelozi a podle toho provest
urcitou optimalizaci treba i jen na urovni jazyka (ne pouzitim assembleru)
atd. Pomalost startu aplikace neni dana velikosti EXE souboru ale mnozstvim
kodu ktery se (treba prave zbytecne) vykonava pri startu jeste pred tim, nez
se aplikace rozbehne - tedy se dostane k Application.Run.

Petr Vones

Odpovedá: Zbysek Hlinka

23. 10. 2002 13:56

On 23 Oct 2002 at 13:09, Petr Vones wrote:

> From: "CERMAK" <CERMAK@procom.cz>
> > Mam velkou databazovou aplikaci. Nevite, jak ji vhodne rozdelit, aby
> > bylo mensi Exe. Balicky, COM, .... Jake mate zkusenosti. Co bude
> > nejjednodussi a nejefektivnejsi na rychlost natahovani casti a na
> > spotrebu pameti.
>
> EXE se do zadne 'pameti' nenatahuje, protoze ve Windows zadna 'pamet'
> neni. Velikost EXE souboru nema mnoho spolecneho s tim, jak rychla
> aplikace je nebo jak rychle se spusti. V beznem procesu je totiz
> stejne namapovano nekolik MB systemovych knihoven, takze tvoje
> aplikace je jen malou casti. Pokud aplikaci slozis z ruznych DLL a
> COMu tak to bude spise pomalejsi, komplikovanejsi a zabirajici vice
> prostredku.

Velky exac je naprd, protoze se komplikovane udrzuje. Pokud program
preroste urcitou mez, je daleko vhodnejsi ho rozsekat na vice-mene
nezavisle moduly. Je s tim sice vic prace na zacatku a beha to pak
trochu pomaleji (coz dnes v drtive vetsine pripadu nema zadny
vyznam), ale lepe se to potom udrzuje a pokud je to dobre navrzene,
pak lze delat snadno zmeny aniz by si clovek rovrtal celou logiku.

Balicky nedoporucuji, ty neresi problem. Jestli muzes pockat na .NET
v Delphi, pak si pockej. Pokud ne, prejdi na Visual Studio nebo to
udelej jako COM.

S pozdravem

Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282

Odpovedá: Jan Sebelík

23. 10. 2002 15:26

> Odesílatel: CERMAK <CERMAK@procom.cz>
> Mam velkou databazovou aplikaci. Nevite, jak ji vhodne rozdelit, aby bylo
> mensi Exe. Balicky, COM, .... Jake mate zkusenosti. Co bude nejjednodussi a
> nejefektivnejsi na rychlost natahovani casti a na spotrebu pameti.
Zajimavy dotaz do diskuse.

Prave mam zakazku na provedeni uprav pro rok 2003 do databazove aplikace -
173000 radku zdrojaku, 10MB exe. Je to proste spatne napsane. Zatim se snazit
to nerozbourat. Pro rok 2004 to napisu uplne od zacatku znova a bude to mit 2MB
(pozor ale na velke dfm s grafikou...).

K dotazu.
Nejde preci jenom o velikost exe, ale o celkove pametove a systemove naroky
aplikace. Osobne jsem toho nazoru, ze i ta nejvetsi aplikace se da
(principialne) resit tak, ze oteviram pouze hlavni formular (bez dat) a hlavni
datovy modul (s konektivitou na databazi). Dalsi jeden-dva-tri formulare si
uzivatel otevre v runtime spolu s daty, OnClose caFree.

Ale pokud by preci jenom melo byt exe mensi, pak treba explicitne (na vyzadani)
loadovane DLL. Asi s balicky, protoze pri uses Forms, DBTables a pod. se
prislusne "masivni" casti VCL prikompiluji do kazdeho DLL.

COM - proc ne, ale principialne to bude podobne jako DLL (zde nepredpokladam
out-of-process objekty se samostatnym exe).

Ale proc ne out-of-process DCOM server?
A mame tady vicevrstvou aplikace s "tenkym" klientem.

Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================

Odpovedá: David Michal

23. 10. 2002 16:48

Zdravim,
Tomuhle uplne nerozumim. Jaky je rozdil v udrzbe nekolika *.pas souboru,
ktere potom zkompiluji do jednoho exe souboru, a udrbou nekolika *.pas
souboru, ktere potom zkompiluji do vice souboru?
David

Velky exac je naprd, protoze se komplikovane udrzuje. Pokud program
preroste urcitou mez, je daleko vhodnejsi ho rozsekat na vice-mene
nezavisle moduly. Je s tim sice vic prace na zacatku a beha to pak
trochu pomaleji (coz dnes v drtive vetsine pripadu nema zadny
vyznam), ale lepe se to potom udrzuje a pokud je to dobre navrzene,
pak lze delat snadno zmeny aniz by si clovek rovrtal celou logiku.

Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.406 / Virus Database: 229 - Release Date: 21/10/2002

Odpovedá: Zbysek Hlinka

23. 10. 2002 19:24

On 23 Oct 2002 at 17:51, David Michal wrote:

> Zdravim,
> Tomuhle uplne nerozumim. Jaky je rozdil v udrzbe nekolika *.pas
> souboru, ktere potom zkompiluji do jednoho exe souboru, a udrbou
> nekolika *.pas souboru, ktere potom zkompiluji do vice souboru? David

Takto pojato zadny. Jde o to navrhnout vhodne rozhrani tak, aby kazdy
modul mohl existovat samostatne, nemel krizove vazby s dalsimi
moduly, nepouzival globalni promenne a data si predaval co nejmensim
poctem jasne definovanych cest. Takovy modul pak muzes lepe testovat
nezavisle na cele aplikaci. Mel by to byt vlastne samostatny objekt,
do ktereho strcis nejaka data, a on ti je vrati zpracovana.

Pokud si dobre navrhnes komunikacni cesty, pak budes moct snaze
pridavat nove vlastnosti do programu (co ja vim, treba prehledy
atp.), o kterych ted jeste nic nevis.

Samozrejme ze tohle lze implementovat i do velkeho exace. Pokud ale
zvolis vhodny komponentovy model, ziskas tim moznost delat upravy
jednotlivych modulu na miru uzivatele (napr. pridavne zakaznicke
moduly), muzes lepe ridit distribuci (pokud si nekdo objedna jen cast
aplikace, tak mu proste nektere moduly nedodas) a podobne radovanky,
ktere ve velkem exaci dost dobre neosetris.

Zcela konkretni priklad z me praxe. Delam dochazkovy program. Puvodni
idea byla, ze vsichni budou mit vsechno. Jenze nekteri zakaznici
chteji zmenit tu tohle, tu onohle, ale individualne pro sebe, dalsim
zakaznikum to dat nemuzu. Typicky je to v pripade vymeny dat s jinymi
programy, predevsim mzdami a personalistikou. S komponentovym modelem
lze napsat individualni modul, a pak mohu vesele updatovat hlavni
aplikaci, ale zakaznicky modul muze zustat stejny a ja si ho dal uz
nevsimam, nemusim myslet na to, ze je treba udelat x kompilaci
velkeho exace pro x zakazniku. Zatim to resim ruznymi nadstavbami, to
ale neni ono.

Do komponentoveho modelu jsem predelal Lokalizator, a tim mi odpadla
rada zbytecnych starosti. Kazdou oblast mam hezky oddelenou, a kdyz
chci pridat novou vec, napisu jen novy modul. Hlavni program si nacte
jen seznam modulu, ktere jsou k dispozici, a s temi pracuje. Pokud
bych to mel ve velkem exaci, musel bych kazdy novy modul implicitne
"vprogramovat" dovnitr.
S pozdravem

Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282

Odpovedá: delfi

23. 10. 2002 19:58

HI,
muzes objasnit jak jsi to myslel s tim .NET?
alda

----- Original Message -----
From: "Zbysek Hlinka" <hlinka@hlinka.cz>
To: <delphi-l@clexpert.cz>
Sent: Wednesday, October 23, 2002 2:52 PM
Subject: Re: Jak rozdelit aplikaci?

> Balicky nedoporucuji, ty neresi problem. Jestli muzes pockat na .NET
> v Delphi, pak si pockej. Pokud ne, prejdi na Visual Studio nebo to
> udelej jako COM.



---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.404 / Virová báze: 228 - datum vydání: 15.10.2002

Odpovedá: Marek Eichler

24. 10. 2002 15:30

Zdravim,

> Balicky nedoporucuji, ty neresi problem. Jestli muzes pockat na .NET
> v Delphi, pak si pockej. Pokud ne, prejdi na Visual Studio nebo to
> udelej jako COM.

Proc balicky ne. Preci kdyz si vytvorim plug-inovy system pomoci
balicku,dostavam stejnou funkcionalitu jako kdyz pouziju COM. Taky mam
zaklad aplikace, ke ktere muzu dynamicky pridavat funkcionalitu, podle toho,
jaky nahrahu balicek a i udrzovani takoveho kodu je jednodussi.

> S pozdravem
>
> Zbysek Hlinka


S pozdravem Marek Eichler

Odpovedá: Macko Martin

24. 10. 2002 11:05

Je nejaky rozdil v zapisu:

var f: TMyForm;

f := TMyForm.Create(self);
f.ShowModal;
f.Free;

nebo s pouzitim globalni promenne:

MyForm := TMyForm.Create(self);
MyForm.ShowModal;
MyForm.Free;

?

-----Original Message-----
From: Petr Vones [mailto:pvones@mbox.vol.cz]
Sent: Wednesday, October 23, 2002 1:10 PM
To: Konference Delphi
Subject: Re: Jak rozdelit aplikaci?


From: "CERMAK" <CERMAK@procom.cz>
> Mam velkou databazovou aplikaci. Nevite, jak ji vhodne rozdelit, aby
> bylo mensi Exe. Balicky, COM, .... Jake mate zkusenosti. Co bude
> nejjednodussi a nejefektivnejsi na rychlost natahovani casti a na
> spotrebu pameti.
lepsi programovat efektivne. Tedy nevytvaret vsechny formulare pri
startu aplikace, ale teprve tehdy az jsou potreba a pak je zase uvolnit,

Odpovedá: ing. Jan Fiala

24. 10. 2002 12:24

Neni. Rozdil je jen v tom, ze Globalni promenna uz v unite existuje,
lokalni si musis vytvaret.
Globalni promennou muzes testovat kdekoliv v programu.
Treba pri prvnim pouziti formular vytvorit a pro dalsich volanich jej
pouze zobrazit a rusit jej az v OnDestroy MainFormu. Tak jednoduse
docilis toho, ze napsane hodnoty pri prvnim volani ti tam pri pristim volani
zustanou.

--
ing. Jan Fiala
mailto:jan.fiala@iol.cz

24.10.2002 Macko Martin:
> Je nejaky rozdil v zapisu:

> var f: TMyForm;

> f := TMyForm.Create(self);
> f.ShowModal;
> f.Free;

> nebo s pouzitim globalni promenne:

> MyForm := TMyForm.Create(self);
> MyForm.ShowModal;
> MyForm.Free;

> ?

> -----Original Message-----
> From: Petr Vones [mailto:pvones@mbox.vol.cz]
> Sent: Wednesday, October 23, 2002 1:10 PM
> To: Konference Delphi
> Subject: Re: Jak rozdelit aplikaci?


> From: "CERMAK" <CERMAK@procom.cz>
>> Mam velkou databazovou aplikaci. Nevite, jak ji vhodne rozdelit, aby
>> bylo mensi Exe. Balicky, COM, .... Jake mate zkusenosti. Co bude
>> nejjednodussi a nejefektivnejsi na rychlost natahovani casti a na
>> spotrebu pameti.
> lepsi programovat efektivne. Tedy nevytvaret vsechny formulare pri
> startu aplikace, ale teprve tehdy az jsou potreba a pak je zase uvolnit,

Odpovedá: Lebeda David

24. 10. 2002 13:57

> Je nejaky rozdil v zapisu:
>
> var f: TMyForm;
>
> f := TMyForm.Create(self);
> f.ShowModal;
> f.Free;
>
> nebo s pouzitim globalni promenne:
>
> MyForm := TMyForm.Create(self);
> MyForm.ShowModal;
> MyForm.Free;

Ahoj,

ve vysledku v tom zadny rozdil neni. Ale pouziti lokalni promenne
ma vyhody:

1) Nehrozi pouziti te promenne omylem na nevhodnem miste, jako
tomu je u globalni promenne, ktera je pristupna kdekoli a kdykoli, i
kdyz je neinicializovana.

2) Zvysuje to citelnost programu, protoze jasne vidis, kde s
formularem zacinas pracovat a kde s nim koncis.

3) A to je mimo: opravdu doporucuji v techto pripadech pouzivat
try... finally, napr.

var f: TMyForm;
 
  f := TMyForm.Create(self);
  try
   f.ShowModal;
 finally
  f.Free;
 end;

Protoze to garantuje, ze Free se opravdu zavola, i kdyz se neco
nepovede a vznikne vyjimka.

David Lebeda

Odpovedá: Jan Sebelík

24. 10. 2002 14:20

> Odesílatel: Macko Martin <martin.macko@m-pro.cz>
> Je nejaky rozdil v zapisu:

> f := TMyForm.Create(self); // f je lokalni
> f.ShowModal;
> f.Free;

> MyForm := TMyForm.Create(self); // MyForm je globalni
> MyForm.ShowModal;
> MyForm.Free;

Rozdil je treba ten, ze f je lokalni, takze mimo proceduru neni odnikud
pristupna, zatimco promenna MyForm pristupna je a po skonceni procedury bude
ukazovat na neexistujici objekt.
A to muze byt docela velky problem, jak uz tady bylo mnohokrat diskutovano.

Nejelegantnejsi zapis je podle me
> with TMyForm.Create(nil) do
> try
> ShowModal;
> finally
> Free
> end;
takze nepotrebuju dokonce ani tu lokalni promennou.
(viz Zakladni kurz Delphi)

Pravda, kdyz uz nas Delphi tlaci do pouzivani techto globalnich promennych, lze
se s tim nejak vyporadat. Pak ale musime vlastnimi silami zaridit, aby MyForm
bylo vzdycky nil, pokud formular neexistuje
(OnDestroy: MyForm:=nil)
a pri vytvareni formulare se vzdycky zeptat, zda formular nahodou uz neexistuje

(if MyForm=nil then MyForm:=TMyForm.Create).

A vubec, pokud jde o modalni formular, ktery ukazujeme uzivateli jenom na
chvili, tak bych tu globalni promennou vubec pro jistotu zrusil.
// var MyForm : TMyForm

Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================

Odpovedá: Martin Schayna

24. 10. 2002 14:20

----- Original Message -----
From: "Jan Sebelík" <honza@haes.cz>
>Nejelegantnejsi zapis je podle me
>> with TMyForm.Create(nil) do
>> try
>> ShowModal;
>> finally
>> Free
>> end;
>takze nepotrebuju dokonce ani tu lokalni promennou.
>(viz Zakladni kurz Delphi)

Ja zase vubec nedoporucuji v ObjectPascalu pouzivat 'with',
protoze to zanasi zmatky a potencialni problemy obzvlast
pokud se zevnitr bloku 'with' volaji funkce zvnejsku
bloku. Napr.

with TMyForm.Create(nil) do
try
  MakeSomething;
  ShowModal;
finally
  Free
end;

chceme aby se rutina (samostatna procedura) MakeSomething
zavolala po vyrobeni formulare. Funguje to do okamziku
kdy (na uplne jinem miste kodu) pridame do tridy
TMyForm metodu se stejnym jmenem MakeSomething.
Pak se uplne zmeni vyznam toho co jsem puvodne napsal
a vyvola se misto rutiny ta metoda. Kod se rozbil a ja
jsem do nej primo ani nezasahl(!)

Ano, samozrejme to resi pravidla pro pojmenovavani
rutin a metod ale v pripade ze je tento kod uvnitr metody
jine tridy a ja volam puvodne metodu te tridy, jsem
v problemu opet.

V nasem projektu jsou 'with' bloky primo zakazane.

Pro uplnost dodavam, ze napr. VB (Buh me chran abych
v nem nemusel psat) to resi a to tak ze uvnitr bloku with
se metody volane zevnitr bloku uvozuji teckou, kdezto
metody/rutiny zvnejsku bloku jsou bez tecky.

Martin Schayna

Odpovedá: Macko Martin

24. 10. 2002 16:29

Asi jsem mel jeste chvilku pockat, mail procist a domyslet nez jsem
zmackl tlacitko odeslat  
Zajimala mne spis souvislost s narocnosti na zdroje, rychlost,
optimalizace z pohledu prekladace apod ...

-----Original Message-----
From: Lebeda David [mailto:david.lebeda@comarr.cz]
Sent: Thursday, October 24, 2002 12:12 PM
To: delphi-l@clexpert.cz
Subject: RE: Jak rozdelit aplikaci?


> Je nejaky rozdil v zapisu:
>
> var f: TMyForm;
>
> f := TMyForm.Create(self);
> f.ShowModal;
> f.Free;
>
> nebo s pouzitim globalni promenne:
>
> MyForm := TMyForm.Create(self);
> MyForm.ShowModal;
> MyForm.Free;

Ahoj,

ve vysledku v tom zadny rozdil neni. Ale pouziti lokalni promenne
ma vyhody:

1) Nehrozi pouziti te promenne omylem na nevhodnem miste, jako
tomu je u globalni promenne, ktera je pristupna kdekoli a kdykoli, i
kdyz je neinicializovana.

2) Zvysuje to citelnost programu, protoze jasne vidis, kde s
formularem zacinas pracovat a kde s nim koncis.

3) A to je mimo: opravdu doporucuji v techto pripadech pouzivat
try... finally, napr.

var f: TMyForm;
 
  f := TMyForm.Create(self);
  try
   f.ShowModal;
 finally
  f.Free;
 end;

Protoze to garantuje, ze Free se opravdu zavola, i kdyz se neco
nepovede a vznikne vyjimka.

David Lebeda

Odpovedá: Petr Vones

24. 10. 2002 18:01

From: "Macko Martin" <martin.macko@m-pro.cz>
> Zajimala mne spis souvislost s narocnosti na zdroje, rychlost, optimalizace
> z pohledu prekladace apod ...

V tomto pripade v tom nejsou zadne podstatne rozdily. Rozdil je jen v tom kam
a jak se ulozi instance toho objektu, a to je velmi jednoducha operace.

Petr Vones

Odpovedá: Erik Salaj

24. 10. 2002 19:35

> Proc balicky ne. Preci kdyz si vytvorim plug-inovy system pomoci
> balicku,dostavam stejnou funkcionalitu jako kdyz pouziju COM. Taky mam
> zaklad aplikace, ke ktere muzu dynamicky pridavat funkcionalitu, podle
toho,
> jaky nahrahu balicek a i udrzovani takoveho kodu je jednodussi.

baliky akurat umoznuju rozdelit velky subor na mensie subory
a nic viac, to nie je porovnatelne s COM funkcionalitou

Erik

Odpovedá: Jiri Foldyna

25. 10. 2002 15:27

> Nejelegantnejsi zapis je podle me
> > with TMyForm.Create(nil) do
> > try
> > ShowModal;
> > finally
> > Free
> > end;
> takze nepotrebuju dokonce ani tu lokalni promennou.
> (viz Zakladni kurz Delphi)

Ahoj,

jen mala troska do mlyna do diskuse: nevim, jak je to v pozdejsich verzich
Delphi, ale v D5 pro uvolnovani formu zasadne pouzivam (tedy pokud
nezapomenu   TForm.Release kvuli event handlerum. Stalo se mi totiz, jsem
jsem asi dva dny hledal chybu, kdy mi aplikace pri zavirani formu OBCAS
vyhlasila AV. Zaboha jsem nebyl schopny to najit, az nahodou jsem zjistil,
ze to zpusobovala obsluha TTimer (obcas jeji provedeni vyslo na okamzik, kdy
se uvolnoval form). Pro vyreseni stacilo pouzit

try
...
finally
  MyForm.Release;
end;

a bylo vymalovano. Duvod lze najit v helpu:

********************************
Use Release to destroy the form and free its associated memory.
Release does not destroy the form until all event handlers of the form and
event handlers of components on the form have finished executing. Any event
handlers of the form should use Release instead of Free. Failing to do so
could lead to an access violation.
********************************

Zdravim

Jiri Foldyna
mailto:jiri.f@avizo.cz